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Dear Sir: 

Appellant now submits its brief after having filed a Notice of Appeal on February 28, 2005. 
A check in the amount of $500.00 is enclosed with this brief. The Commissioner is authorized to 
charge Deposit Account No. 50-1482 in the name of Carlson, Gaskey & Olds for any additional 
fees or credit the account for any overpayment. 



Introduction 

At least one element of every claim is missing from the reference relied upon by the 
Examiner when rejecting the claims under 35 U.S.C. §102. The rejection must be reversed. 
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Real Party in Interest 

Hamilton Sundstrand Corporation, which is the Assignee of this application, is the real 
party in interest. Hamilton Sundstrand Corporation is a business unit of United Technologies 
Corporation. 

Related Appeals and Interferences 

There are no related appeals or interferences. 

Status of the Claims 

Claims 1-23 are currently pending and stand rejected under 35 U.S.C. §102. 

Status of Amendments 

There are no unentered amendments. 

Summary of Claimed Sub ject Matter 

This invention generally relates to electronically processing transactions throughout an 
entire order-to-cash trading cycle. Prior to this invention, no one has provided a fully integrated 
system where a supplier, shipper and customer can all utilize a single transaction identifier 
during all phases of the order-to-cash cycle of a transaction. Before this invention, there were 
redundancies during the normal order-to-cash trading cycle during the ordering, releasing, 
shipping, receiving and paying stages of the cycle. With this invention, the flow of trade is 
enhanced by utilizing electronic transaction capabilities to minimize paperwork and 
redundancies in the transaction process. (Paragraphs 3 and 4) 
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Independent claim 1 recites: 

1. A method of electronically handling transactions, comprising the 
steps of: 

establishing a transaction identifier that is used during all stages of 
an order-to-cash trading cycle; 

electronically storing the transaction identifier such that the 
identifier is remotely accessible by a plurality of users; 

linking supplier information with the transaction identifier; 

linking purchaser information with the transaction identifier; 

updating status information indicating the status of the transaction 
during a corresponding phase of the transaction; and 

linking the status information to the transaction identifier. 

Claim 1 reads on the example illustrated embodiment as follows. A transaction identifier 
40, which in one example comprises a single barcode, represents a plurality of pieces of 
information. At least supplier information and purchaser information is linked with the 
transaction identifier 40. (Paragraph 22) 

The example of Figure 1 includes a tracking module 30 for storing the example 
transaction identifier 40 such that the identifier is remotely accessible by a plurality of users such 
as a purchaser, supplier and carrier. The single transaction identifier 40 provides the system the 
ability to link all information regarding the transaction so that it can be readily accessed by a 
variety of individuals at remote locations by simply entering the transaction identifier into an 
appropriate computer or other device, for example. (Paragraph 22) 

Upon receiving an order, the supplier preferably provides information to the example 
system 20 that results in the generation of the transaction identifier 40. (Paragraph 23) Once the 
order has been appropriately arranged, it is then provided to a carrier for shipment. In one 
example, the carrier enters the transaction identifier into the carrier's database, which is also 
tracked by the example tracking module 30. At this phase of the transaction, the tracking module 
30 preferably contains or has access to information regarding the contents of the order, the 
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carrier, the date of receipt by the carrier and any other relevant information entered by the 
supplier or the carrier. While in route, the carrier may update the transaction information by 
providing information to the tracking module 30 regarding location of the shipment, expected 
arrival date, etc. All such information in this example is linked to and accessible using the 
identifier 40. (Paragraph 24) 

Information linked to the transaction identifier may further include information pertaining 
to the carrier arriving at a location specified by the customer and providing an indication that the 
shipment has been delivered. In one example, the carrier is able to indicate other information 
such as time of delivery or conditions of the shipment upon delivery, for example. At that time, 
the tracking module 30 has verification that the shipment has been completed and the 
information regarding the transaction is appropriately updated. (Paragraph 25) 

At this stage of the transaction, the transaction identifier 40 preferably is directly linked 
with or contains information regarding a customer identification number, the purchase order 
number, a shipment release number, a packing slip number or an invoice number. Having all of 
this information associated with or contained within the transaction identifier eliminates the 
previously required steps of completing various invoices and receipt documents. 

In the illustrated example, the tracking module 30 maintains information regarding the 
transaction and automatically updates it upon receiving a communication from one or more of 
the other modules that are linked into the system 20. 

No previous system had the ability to update status information as recited in claim 1. The 
entire phase of the transaction between receipt of an order and delivery to the customer had not 
been linked to a transaction identifier as claimed in claim 1. There previously had been no 
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ability to update status information and link it to a transaction identifier as provided by the 

example embodiment upon which claim 1 reads. 

Dependent claim 4 recites: 

4. The method of claim 1, including automatically facilitating 
payment from a customer to a supplier responsive to determining that a selected 
portion of the transaction is complete. 

There are several disclosed examples upon which claim 4 reads. In one example as 
shown in Figure 4, once a supplier provides an order to a shipper or carrier, the system 
automatically sends a message to the customer module 28 notifying the customer module of the 
beginning of shipment. In some instances, an agreement between the supplier and customer 
requires cash before delivery. The customer module 28 can respond to such a message by 
instigating an appropriate payment procedure. This is one example of enhancing a supplier 
receiving payment more quickly than previous arrangements where a variety of individuals must 
be involved to track appropriate information and complete necessary paperwork that was 
otherwise required. (Paragraph 30) 

In another example, the supplier module 24 calculates a payment due date based upon 
receipt of a message regarding a particular status of the shipment. Such an example allows a 
supplier to more accurately track accounts payable and estimated or actual due dates, for 
example. (Paragraph 31) 

In one example, electronic payment is accomplished once a customer module 28 receives 
notification of an appropriate status of an appropriate portion of the transaction. In one example, 
the customer module 28 communicates with the supplier module 24 directly to indicate a transfer 
of funds from the appropriate customer account into the appropriate supplier account using an 
electronic fund transfer mechanism. (Paragraph 32) 
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Claim 6 recites: 

6. The method of claim 1, including automatically updating the status 
information responsive to remotely received information regarding stages of the 
transaction. 

This claim reads on, for example, when a shipper 32 supplies information regarding a 
status of the shipment from a remote location. (Paragraphs 26 and 27) In one example, the 
tracking module 30 maintains information regarding the transaction and automatically updates it 
upon receiving such a communication. (Paragraph 28) 

Claim 22 particularly recites that the corresponding phase of the transaction recited in 
claim 1 is a phase between an order from the purchaser and receipt by the purchaser. 

Claim 23 particularly recites updating status information responsive to input from a 

carrier. 

Independent claim 7 recites: 

7. A system for electronically processing transactions, comprising: 
a transaction identifier that identifies a transaction; and 

a tracking module that includes status information regarding the 
transaction and updates the status information during stages of the transaction, the 
tracking module providing access to the status information to a plurality of users 
such that a user of the system can automatically access the status information by 
using the transaction identifier. 

This claim reads upon the example embodiment described above. 
Claim 14 provides: 

14. The system of claim 7, wherein the tracking module communicates 
with a plurality of remotely located input devices and where the input devices 
provide status information regarding the transaction. 

Claim 15 recites: 

15. The system of claim 14, wherein at least one of the input devices is 
a shipper input device that a shipper uses to enter status information regarding the 
shipment and delivery portions of the transaction. 
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Claim 16 relates to billing and payment. 

16. The system of claim 7, including a billing module that 
communicates with the tracking module and wherein the billing module 
automatically facilitates fund transfers between a customer account and a supplier 
account responsive to receiving shipment confirmation information from the 
tracking module. 

Claim 20 particularly recites that the tracking module updates status information 

indicative of a stage of the transaction between a customer order and receipt by the customer. 

Claim 21 particularly recites that the plurality of users includes a carrier. 

Independent claim 18 recites: 

18. A computer readable medium containing a plurality of computer 
executable instructions for electronically processing transactions, comprising: 

a first instruction module establishing a transaction identifier that 
is used during all stages of a transaction; 

a second instruction module electronically storing the transaction 
identifier such that the identifier is remotely accessible by a plurality of users; 

a third instruction module linking supplier information with the 
transaction identifier; 

a fourth instruction module linking purchaser information with the 
transaction identifier; 

a fifth instruction module updating status information indicating 
the status of the transaction during a corresponding phase of the transaction; 

a sixth instruction module linking the status information to the 
transaction identifier; and 

a seventh instruction module automatically providing at least 
selected portions of the information linked to the transaction identifier responsive 
to a user accessing the transaction identifier. 

Claim 19 adds that the status information includes information regarding the transaction 
at a stage between an order by the purchaser and receipt by the purchaser. 
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Grounds of Rejection to be Reviewed on Appeal 

Claims 1-23 were rejected under 35 U.S.C. §102 based upon U.S. Patent No. 6,015,167 
(the "Savino" reference). The problem with the Examiner's rejection is that nothing in that 
reference discloses updating information as recited in claim 1 and linking the updated status 
information to the transaction identifier. Nothing in the Savino reference teaches a tracking 
module as recited in claim 7. Nothing in the Savino reference teaches a computer readable 
medium as recited in claim 18 that includes an instruction module for updating status 
information indicating the status of the transaction during a corresponding phase of the 
transaction or another instruction module linking the status information to the transaction 
identifier. As at least one element of each of the independent claims cannot be found in the 
Savino reference. There is no anticipation. 

Argument 

It is axiomatic that in order for a reference to anticipate a claim, every element of the 
claim must be expressly or inherently disclosed in that reference. In this instance, the Savino 
reference is not as comprehensive as the claimed invention and there is no anticipation. The 
Savino reference does teach generating a barcode shipping label that links, in a database or 
supplier digital processor, a plurality of predetermined relevant purchase and shipping 
information. The teachings of the Savino reference, however, are limited to the time when a 
customer places an order. There is no updating of any information in the Savino reference that 
corresponds to the type of information encompassed within Applicant's claimed arrangement. 
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Column 3, lines 33-47 of the Savino reference teach: 

For example, as illustrated in Fig. 5, a barcode value represented by the barcode 
500 provided in accordance with the present invention is stored in the database 14 
and is linked in the database by conventional software methods to various 
variables or aspects of purchase and shipping information of a purchase order 
such as customer name and address 502, packing slip number 504, customer 
purchase order number 506, box quantity number 508, part quantity number 510, 
customer part number 512, manufacturer part number 514, shipping date 516, etc. 
Thus, the supplier or customer if so equipped, need only scan a single barcode to 
retrieve from the database all relevant purchase and shipping information 
associated with a purchase order. 

Further, the Savino reference teaches in column 4, lines 17-35: 

The supplier digital processor 12, upon receiving the authorization command, 
assigns a barcode and generates a barcode shipping label (step 412). The barcode 
links in the database 14 or supplier digital processor 12 a plurality of 
predetermined relevant purchase and shipping information entered by the 
customer and associated with a purchase order. Because the barcode shipping 
label provides information directly entered by the customer, corruption of 
purchase order information through re-entry of the information by the supplier 
is avoided. The barcode may be scanned (step 414) by the supplier digital 
processor 12 or the customer digital processor 16 to access from the database 14 a 
plurality of predetermined, relevant purchase and shipping information associated 
with the customer's purchase order including, for example, customer name and 
address, packing slip number, purchase order number, box quantity number, part 
quantity number, customer part number, manufacturer part numbers, shipping 
date, etc. (Emphasis supplied) 

Later in column 4, the Savino reference teaches that, "One advantage of the system 
embodying the present invention is that purchase and shipping information is only entered by the 
customer in order to ensure reliability of order information. There is no re-entry of purchase 
order information into the database of the supplier which can lead to corruption of the originally 
supplied purchase order information." (Emphasis supplied) 

It is clear from the teachings of the Savino reference that there is no updating of any 
status information regarding any portion of the order-to-cash trading cycle after the customer 
enters the information that results in generation of the barcode. There is nothing within the 
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Savino reference that contemplates a carrier providing updated information regarding shipping 
status, for example. There is nothing within the Savino reference that indicates that a payment 
for a shipment can be facilitated using that barcode. Such features cannot be found in the 
reference and are not inherently included. 

The Examiner appears to be relying upon a statement in column 5 beginning at line 18 
where Savino teaches, "A sixth advantage is that a customer or supplier can easily access 
shipping and receiving status information pertaining to purchase orders and parts shipped." This 
single statement cannot be taken out of context in order to manufacture an anticipation rejection 
of Applicant's pending claims. That statement must be taken in context with the remaining 
teachings of the Savino reference which, as quoted above, are unequivocal that the only 
information linked with the barcode is the information provided by the customer when placing 
the order (of course, some of the shipper information may be automatically generated by the 
shipper's portion of the system, but even that gets linked to the barcode only at the time when the 
customer places the order.) There is nothing in the Savino reference that teaches later providing 
additional information or updating information regarding the status of an order along the way. 

Additionally, none of the claims can be considered obvious because any modification to 
the Savino reference that would bring it closer to Applicant's claimed invention would be 
contrary to the express teachings of the Savino reference. As quoted above, the Savino reference 
is very protective of what information gets linked to the barcode of that reference. It only occurs 
responsive to the customer input. Therefore, if one were to modify the teachings of the Savino 
reference to try to render that consistent with Applicant's claimed invention, a feature of the 
teachings of Savino would be eliminated and that is not permissible when attempting to establish 
a prima facie case of obviousness. 
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CLAIMS 1-3 ARE ALLOWABLE 

Claim 1 includes, in part, "updating status information indicating the status of the 
transaction during a corresponding phase of the transaction and linking the status information to 
the transaction identifier." That is nowhere expressly or inherently within the Savino reference. 
There is no anticipation. 

CLAIM 4 IS ALLOWABLE 

Claim 4 cannot be considered anticipated by any stretch of the Savino reference. Nothing 
in the Savino reference relates to, "automatically facilitating payment from a customer to a 
supplier responsive to determining that a selected portion of the transaction is complete." 

CLAIM 5 IS ALLOWABLE 

Claim 5, which depends from claim 4, further recites, "automatically determining 
payment schedule terms based upon selected criteria using the determined completion of the 
selected portion of the transaction." Nothing in the Savino reference can be interpreted in a 
manner that would render claim 5 anticipated. 

CLAIM 6 IS ALLOWABLE 

Claim 6 pertains to remotely received information used for automatically updating the 
status information regarding stages of the transaction. Nothing in the Savino reference pertains 
to this. The only information linked with the barcode in the Savino reference exists at the time 
that a customer places an order. There is no remotely received information regarding stages of 
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the transaction after that point in the Savino reference. Claim 6 cannot possibly be considered 
anticipated. 

CLAIM 22 IS ALLOWABLE 

Claim 22 particularly recites that the "corresponding phase of the transaction is a phase 
between an order from the purchaser and receipt by the purchaser." As mentioned above, the 
Savino reference does not have any information linked to the barcode after the order is placed by 
the customer. Therefore, any phase of the transaction that fits within the timeframe recited in 
claim 22 is necessarily outside of the scope of the Savino reference and claim 22 is not 
anticipated. 

CLAIM 23 IS ALLOWABLE 

Claim 23 particularly recites, "updating status information responsive to input from a 
carrier." The Savino reference only accepts information from a customer when generating the 
barcode of that reference. The Savino reference expressly teaches the opposite of allowing a 
carrier to provide information that would get linked with the barcode. Claim 23 cannot possibly 
be considered anticipated by the Savino reference. 

CLAIMS 7-9 AND 14 ARE NOT ANTICIPATED 

Claim 7 recites, in part, "a tracking module that includes status information regarding the 
transaction and updates the status information during stages of the transaction." Nothing in the 
Savino reference constitutes a tracking module as recited in claim 7. There is nothing that 
updates status information during stages of the transaction in the Savino reference. The barcode 
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generated in that reference is a shipping label affixed to a package that is linked to information 
available only up to the point when a customer places an order as pointed out above. There is no 
updating of information beyond that point in the Savino reference and claim 7 cannot be 
considered anticipated. 

CLAIMS 10-13 ARE NOT ANTICIPATED 

Each of claims 10-13 recites a particular module or relationship between modules related 
to status information that are not taught in the Savino reference. None of these claims can be 
considered anticipated. 

CLAIM 15 IS NOT ANTICIPATED 

Claim 15 particularly recites that, "at least one of the input devices is a shipper input 
device that a shipper uses to enter status information regarding the shipment and delivery 
portions of the transaction." The Savino reference never touches on this and this claim cannot be 
considered anticipated. 

CLAIM 16 IS NOT ANTICIPATED 

Claim 16 particularly recites, "a billing module that... automatically facilitates fund 
transfers between a customer account and a supplier account." There is nothing in the Savino 
reference that comes anywhere near the limitations of claim 16 and there is no anticipation. 
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CLAIM 20 IS NOT ANTICIPATED 

Claim 20 particularly recites that the tracking module, "updates status information 
indicative of a stage of the transaction between a customer order and receipt by the customer." 
There is nothing in the Savino reference that does anything with the barcode after the customer 
places the order. Only the previously stored but not updated barcode information could be 
retrieved to review the information that was linked to the barcode prior to or at the time of the 
customer placing the order. There is nothing within the Savino reference that relates to updating 
status information regarding a stage of a transaction after the customer orders. Claim 20 is not 
possibly anticipated. 

CLAIM 21 IS NOT ANTICIPATED 

Claim 21 particularly recites that one of the users is a carrier. The Savino reference does 
not contemplate or allow for a carrier to enter information or provide information for updating a 
status of a transaction that gets linked to the barcode in the Savino reference. That reference 
clearly teaches that the barcode is generated only responsive to the customer input. 

CLAIM 18 IS ALLOWABLE 

There is no teaching within the Savino reference that anticipates a computer readable 
medium as recited in claim 18. There is nothing in the Savino reference for, "updating status 
information indicting the status of the transaction during a corresponding phase of the 
transaction" or "linking the status information to the transaction identifier." There is no 
anticipation. 
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CLAIM 19 IS ALLOWABLE 



The particular stages of the transaction recited in claim 19 are not discussed or 
contemplated within the teachings of the Savino reference as being linked in anyway with the 
barcode of that reference. Claim 19 is not anticipated. 



The Examiner's interpretation of the Savino reference finds many things within that 
reference that are not there. There is no express or inherent teaching of the particular 
arrangement recited in Applicant's claims, which goes beyond the teachings of a shipping label 
barcode in the Savino reference. Applicant's claimed invention provides further capabilities not 
contemplated by the Savino reference. The rejection under 35 U.S.C. §102 must be reversed. 

There is no basis for maintaining a rejection of Applicant's claims. This case is in 
condition for allowance. 



CONCLUSION 



Respectfully submitted, 



CARLSON, GASKEY & OLDS 




David J. Gfcskey X\ 
Registration No. 3x13^ 
400 W. Maple Rd., Ste^350 
Birmingham, MI 48009 
(248) 988-8360 



Dated: April 28, 2005 
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CERTIFICATE OF MAILING 

I hereby certify that the enclosed Appeal Brief is being deposited with the United States Postal Service as First Class 
Mail, postage prepaid, in an envelope addressed to Mail Stop Appeal Brief - Patents, Commissioner for Patents, P. O. Box 
1450, Alexandria, VA 22313-1450 on April 28, 2005. 
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APPENDIX OF CLAIMS 

1. A method of electronically handling transactions, comprising the steps of: 
establishing a transaction identifier that is used during all stages of an order-to- 
cash trading cycle; 

electronically storing the transaction identifier such that the identifier is remotely 
accessible by a plurality of users; 

linking supplier information with the transaction identifier; 

linking purchaser information with the transaction identifier; 

updating status information indicating the status of the transaction during a 
corresponding phase of the transaction; and 

linking the status information to the transaction identifier. 

2. The method of claim 1, including automatically providing at least selected 
portions of the information linked to the transaction identifier to a user. 

3. The method of claim 1, including providing at least selected portions of the 
information linked to the transaction identifier to a user responsive to the user accessing the 
transaction identifier. 

4. The method of claim 1, including automatically facilitating payment from a 
customer to a supplier responsive to determining that a selected portion of the transaction is 
complete. 

5. The method of claim 4, including automatically determining payment schedule 
terms based upon selected criteria using the determined completion of the selected portion of the 
transaction. 

6. The method of claim 1, including automatically updating the status information 
responsive to remotely received information regarding stages of the transaction. 
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7. A system for electronically processing transactions, comprising: 
a transaction identifier that identifies a transaction; and 

a tracking module that includes status information regarding the transaction and 
updates the status information during stages of the transaction, the tracking module providing 
access to the status information to a plurality of users such that a user of the system can 
automatically access the status information by using the transaction identifier. 

8. The system of claim 7, wherein the transaction identifier comprises a single 
barcode representing a number. 

9. The system of claim 8, wherein the transaction identifier includes information 
identifying a customer, a purchase order number, shipment release number and packing slip 
number. 

10. The system of claim 7, including a customer module that includes information 
regarding at least one customer, the customer module facilitating the tracking module obtaining 
information regarding the customer and the status of the transaction where the status relates to 
the customer, the customer module linking the customer information with the transaction 
identifier. 

11. The system of claim 10, including a supplier module that includes information 
regarding at least one supplier, the supplier module facilitating the tracking module obtaining 
information regarding the supplier and the status of the transaction where the status relates to the 
supplier, the supplier module linking the supplier information with the transaction identifier. 

12. The system of claim 11, wherein the tracking, customer and supplier modules all 
each communicate with the other modules. 

13. The system of claim 11, wherein the tracking, customer and supplier modules are 
each located remotely from the other modules. 
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14. The system of claim 7, wherein the tracking module communicates with a 
plurality of remotely located input devices and where the input devices provide status 
information regarding the transaction. 

15. The system of claim 14, wherein at least one of the input devices is a shipper 
input device that a shipper uses to enter status information regarding the shipment and delivery 
portions of the transaction. 

16. The system of claim 7, including a billing module that communicates with the 
tracking module and wherein the billing module automatically facilitates fund transfers between 
a customer account and a supplier account responsive to receiving shipment confirmation 
information from the tracking module. 

17. The system of claim 7, wherein the tracking module comprises software. 
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18. A computer readable medium containing a plurality of computer executable 
instructions for electronically processing transactions, comprising: 

a first instruction module establishing a transaction identifier that is used during 
all stages of a transaction; 

a second instruction module electronically storing the transaction identifier such 
that the identifier is remotely accessible by a plurality of users; 

a third instruction module linking supplier information with the transaction 

identifier; 

a fourth instruction module linking purchaser information with the transaction 

identifier; 

a fifth instruction module updating status information indicating the status of the 
transaction during a corresponding phase of the transaction; 

a sixth instruction module linking the status information to the transaction 

identifier; and 

a seventh instruction module automatically providing at least selected portions of 
the information linked to the transaction identifier responsive to a user accessing the transaction 
identifier. 

19. The computer readable medium of claim 18, wherein the status information 
includes information regarding the transaction at a stage between an order by the purchaser and 
receipt by the purchaser. 

20. The system of claim 7, wherein the tracking module updates status information 
indicative of a stage of the transaction between a customer order and receipt by the customer. 

21. The system of claim 7, wherein the plurality of users includes a carrier. 

22. The method of claim 1, wherein the corresponding phase of the transaction is a 
phase between an order from the purchaser and receipt by the purchaser. 
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23. The method of claim 1, including updating status information responsive to input 
from a carrier. 
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